S3G (Super 3G) is a standard the standardization organization 3GPP is now promoting international standardization as LTE (Long Term Evolution) in an effort to achieve a significant improvement in performance of the third-generation (3G) cellular system. The standard achieves high-speed transmission in mobile communication, and provides an advanced service environment such as high-speed video distribution. Furthermore, it is expected as a system to provide effective frequency utilization.
FIG. 10 illustrates a configuration of an S3G system.
Each wireless base station (E-UTRAN Node-B, abbreviated as eNB) has a function as a wireless base station (Node-B) in generations before S3G and a function as a radio network controller (RNC).
An access gateway (aGW) manages and controls a plurality of eNBs, and relays transmission between an user equipment (UE) and an inter access system anchor (IASA). The IASA has a router function and is connected to an IP Multimedia Subsystem (IMS). It is also connected to a home subscriber service (HSS) for storing subscriber profiles.
Since this system is upgraded from an existing circuit-switched mobile system until a conventional 3G system including voice communication to an all-IP mobile system, the VoIP is also applied to voice communication, which can be subjected to packet communication together with data communication.
FIG. 11 illustrates a protocol stack that transforms real-time data (such as voice communication call) in the S3G system into IP packets. Table 1 lists a functional overview of each protocol.
TABLE 1Protocol overviewProtocolFunctional overviewRegulationPHY/EtherPhysical layer/Ethernet(R)IEEE802-These are defined as basicrelatedinterfaces for LAN/WAN, and eitherregulationPhysical layer or Ethernet(R), orvarying combinations of both can beused.MACMedium Access ControlTS.25.321Performs, for example, scheduling,priority control, error correctionby HARQ (Hybrid Automatic Repeatrequest), and transport formatselection.RLCRadio Link ControlTS.25.322Error correction by ARQIn-sequence delivery of an upper-layer PDU (Protocol Data Unit)GREGeneric Routing EncapsulationRFC2784Used for encapsulation of otherprotocols.S1-FPS1 Interface Frame PacketA Protocol applied to the interface(S1 Interface) between an aGW and aneNB.The detail of the current protocolfield is undefined.PDCPPacket Data Convergence ProtocolTS.25.323Performs header compression (ROHC:RObust Header Compression) ofTCP/IP.MIPMobile IPRFC3220Manages correspondence between a(IPv4)Home Address (HoA) used by a MobileRFC3775Node (MN) in the home link (the(IPv6)network to which the MN originallybelongs) and a Care of Address (CoA)used in an external link (a visitednetwork by the MN).IPSecIP Security protocolRFC2002,Ensures security (for encryption) in2406the IP layer.A transport mode and a tunnel modeare available.IPInternet ProtocolRFC791Layer 3 function used in theInternet. Provides a data routingfunction.UDPUser Datagram ProtocolRFC768A connectionless transmissionprotocolLow reliability but light-loadprocessing.RTPReal-time Transport ProtocolRFC1889Provides a framework fortransmission of real-time media suchas audio and video.Uses a profile or a payload formatdepending on application.RTCPRTP Control ProtocolRFC1889Controls a session for datatransmission in RTP (Real-timeTransport Protocol), checks datatransmission, and transmitsinformation between a sender and areceiver.
Real-time data is transmitted using a RTP/UDP/IP header.
The RTP/UDP/IP header constitutes a significant overhead for audio data, and attachment of the header without modification leads to low communication efficiency. Furthermore, line quality in the wireless zone is lower than that in the cable zone, and the wireless zone has narrow bandwidth. This requires further header compression compared to the cable zone.
Thus, a PDCP protocol is applied between an aGW and a UE to perform Robust Header Compression (ROHC) for an RTP/UDP/IP header. The wireless zone can increase the utilization efficiency of transmission (wireless) bandwidth.
The ROHC performed by the PDCP protocol has three compression states; IR, FO, and SO depending on the compression level (see Table 2).
TABLE 2Compression states of ROHC(1)Initialization andInitialization state:Refresh (IR)Transmits uncompressed fullheader.(2)First Order (FO)Header updating:Transmits parts such as adestination address of whichthe value ordinarily doesnot vary, but varies by achange in session.(3)Second Order (SO)Operation state:Transmits only minimumfield.
In the ROHC, three transmission modes (U mode, O mode, and R mode) are defined (see Table 3), and these modes can mutually transfer from one to another during communication.
TABLE 3Transmission modes of ROHCU-mode(1) Surely delivers data to UE byNo feedback fromsending the same data severalUE (decompressor)times (optimistic approach).(2) Makes a transition to a lowerstate periodically (timeout).(3) Makes a transition to a lowerstate if the compression patternis changed by a significantchange in a header (need forupdates).O-mode(1) The ideas of “optimisticIrregular feedapproach” and “need for update”back from UEare the same as those of the U-(decompressor)mode.(2) Uses no Timeout.(3) Makes a transition to anotherstate after recognition of areception state of UE(decompressor) by feedback fromthe UE (decompressor).R-mode(1) Makes a transition to anRegular feedbackupper state using only feedbackfrom UEfrom UE (decompressor), without(decompressor)using the optimistic approach(secure reference).(2) Makes a transition to a lowerstate by “need for updates” or byerror reception notification fromUE (decompressor).
These three transmission modes each have the three compression states (IR, FO, and SO) illustrated in Table 2 (see FIG. 12).    Patent Reference 1: Japanese Translation of PCT international application No. 2004-533792    Patent Reference 2: Japanese Translation of PCT international application No. 2004-502361    Patent Reference 3: Japanese Translation of PCT international application No. 2005-522944    Non-Patent Reference 1: 3GPP (TM) TS25.321    Non-Patent Reference 2: 3GPP (TM) TS25.322    Non-Patent Reference 3: 3GPP (TM) TS25.323    Non-Patent Reference 4: RFC3095
Preferably, the transmission modes and the header compression states above are selectively applied depending on a system and a service. For example, since a wireless band for voice communication is limited in a mobile system, an improvement in the utilization efficiency is indispensable and transmission of useless data must be avoided as much as possible.
In that case, for example, in the U mode, multiple transmission of the same data segment by “optimistic approach” should be avoided as much as possible because it causes the utilization efficiency to decrease. In addition, since header information transmitted in the IR state or the FO state must be minimized, transition from a lower state to an upper state (IR to FO, FO to SO, or IR to SO) is preferably made immediately. On the contrary, the timer value for transition from an upper state to a lower state (SO to FO, FO to IR, or SO to IR) is preferably large.
The O mode or the R mode, which needs a response from UE, affects the upstream band. Furthermore, the round-trip time is long because of notification from a UE to an aGW, which may not be available for real-time voice communication. For example, when a reception error at a UE 400 is notified to an aGW (an ROHC compressor), selection of transition of the compression state is delayed in response to the delayed arrival of the notification to the aGW, which may cause needless wireless transmission in the downstream direction.
(Application Example of ROHC)
When ROHC processing is applied to voice communication in a mobile system, only the U mode, which does not perform feedback from a UE to an aGW, is used, and state transition in the ROHC processing is preferably limited to only the transition between the IR state and the SO state, as illustrated in FIG. 13.
Specifically, the transition from the IR state to the SO state (an upper state) is performed, for example, by transmission of one packet of header-uncompressed data (hereinafter referred to uncompressed data). The transition from the SO state to the IR state (a lower state) is performed, for example, at the end of a timer value (100 ms).
FIG. 14 illustrates a header format of IP/UDP/RTP. As illustrated in FIG. 14, all the headers (40 to 100 bytes) are transmitted in the IR state, whereas only the sequence number (SN, 2 bytes) in the RTP header is transmitted in the SO state.
FIG. 15 illustrates a transmission image (direction from an aGW to a UE) of audio packets in this exemplary application. In the drawing, the audio packets are transmitted at constant intervals (20 ms), and uncompressed data segments are transmitted at intervals of 100 ms.
FIGS. 16 and 17 illustrate examples of packet formats after processing in function blocks of two nodes. FIGS. 16 and 17 illustrate exemplary formats in an uncompressed condition and in a compressed condition, respectively.
In both cases, ciphering is performed from the PDCP field to the AMR field by a PDCP processor of an aGW, and deciphering is performed by the UE. If a packet size exceeds the RLC-PDU length in cases of RCL processing in an eNB, the packet is divided into multiple RLC protocol data units (RLC-PDUs). If a space is generated by the division, padding data is inserted. In the example illustrated in FIG. 16, the audio packet is divided into three RLC-PDUs in the uncompressed condition. In the example of the compressed condition illustrated in FIG. 17, the audio packet is transmitted in one packet without division.
FIG. 18 illustrates a system configuration of the ROHC processing applied to voice transmission in the above mobile system. FIG. 19 illustrates a processing sequence in the system. In FIG. 19, however, only the processing sequence for the downstream (from the NW to the UE) communication is illustrated.
The system illustrated in FIG. 18 includes, for example, an upper-level network device 100 (hereinafter also referred to as NW 100) that constitutes an upper-level network (NW) equivalent to an IASA illustrated in FIG. 10, an aGW 200, an eNB 300, and a UE 400.
The aGW 200 includes an upper-level device interface (IF) 201, a PDCP processor 202, an S1-FP transmission processor 203, and an S1-FP reception processor 204. The eNB 300 includes an S1-FP reception processor 301, an S1-FP transmission processor 302, an RLC processor 303, a MAC processor 304, and a wireless terminator (a physical layer (PHY) processor) 305. Hereinafter, the MAC processor and the PHY processor may be collectively called MAC/PHY processor.
Furthermore, the PDCP processor 202 of the aGW 200 includes an ROHC controller 221, an ROHC compressor 222, a ciphering (encryption) processor 223, a deciphering (decryption) processor 224, and an ROHC decoder (ROHC decompressor) 225. The RLC processor 303 of the eNB 300 includes a PDCP-SDU divider (an RLC-PDU generator) 331 and a PDCP-SDU generator (an RLC terminator) 332.
The UE 400 includes, for example, a MAC/PHY processor 401, an RLC processor 402, and a PDCP processor 403 as illustrated in FIG. 18, focusing attention on downstream functions.
In the system having such a configuration, first, downstream (direction from the NW 100 to the UE 400) processing for audio data (the processing sequence illustrated in FIG. 19) is described. In the aGW 200, audio data (AMR/RTP/UDP/IP packet data) received from the upper-level network through the upper-level device interface 201 is applied to the PDCP processor 202. After PDCP protocol processing (ROHC processing) by the ROHC compressor 222, the data is ciphered (encrypted) by the ciphering processor 223, and then is transmitted to the S1-FP transmission processor 203.
The S1-FP transmission processor 203 converts the protocol fields of the packet received from the PDCP processor 202 (the ciphering processor 223) into a protocol (S1-FP) used in the inter-device IF between the aGW 200 and the eNB 300 (for example, attachment of an S1-FP header), and then transmits the packet to the eNB 300.
In the eNB 300, the S1-FP reception processor 301 receives the packet (the S1-FP packet) transmitted from the aGW 200 (the S1-FP transmission processor 203), and then transmits the packet to the RLC processor 303, for example, after termination processing of the S1-FP header.
In the RLC processor 303, the PDCP-SDU divider (the RLC-PDU generator) 331 generates data of the RLC layer (RLC-PDU) from the received packet (the PDCP packet) transmitted from the S1-FP reception processor 301. In other words, the divider 331 divides the SDU (PDCP-SDU) of the received packet into RLC packets (RLC-PDUs) as needed, and then transmits them to the MAC processor 304.
The MAC processor 304 transmits the RLC packet (RLC-PDU) from the RLC processor 303 to the wireless terminator (the PHY processor) 305 after the required MAC processing at the MAC layer. The wireless terminator 305 generates a transmission wireless signal from the data that is subjected to such MAC processing, and then transmits the signal to the UE 400.
In the UE 400, the MAC/PHY processor 401 subjects the wireless signal received from the eNB 300 to required processing (termination processing) at the physical layer and the MAC layer, the RLC processor 402 subjects the signal to RLC termination processing, and then the PDCP processor 403 subjects the signal to deciphering processing and PDCP termination processing (for example, decompression processing) to decode the audio data (AMR/RTP/UDP/IP packet data).
On the contrary, the process of upstream audio data is the reverse of the above process. Consequently, in the UE 400, the audio data to be transmitted is subjected to required processing in the PDCP, ciphering (encryption), and the MAC/PHY protocol, and then is transmitted to the eNB 300 by a wireless signal. The eNB 300 subjects the signal received from the UE 400 to required processing at the physical layer and the MAC layer in the wireless terminator 305 and the MAC processor 304, and then transmits the signal to the PDCP-SDU generator (the RLC termination processor) 332 in the RLC processor 303 to generate a PDCP packet (PDCP-SDU). The PDCP packet is transmitted to the aGW 200 after conversion into the inter-device IF protocol (S1-FP) in the S1-FP transmission processor 302.
In the aGW 200, the upstream data (the S1-FP packet) transmitted from the eNB 300 is received by the S1-FP reception processor 204, and then is transmitted to the PDCP processor 202 after converting into the inter-device IF protocol (PDCP). Then, the data is subjected to deciphering processing and ROHC decoding processing by the deciphering processor 224 and the ROHC decoder 225, respectively, in the PDCP processor 202, and then is transmitted to the NW 100 through the upper-level device IF 201.
As described above, header compression by the ROHC in PDCP leads to efficient utilization of a transmission line. However, as schematically illustrated in FIG. 20, for example, if missing of an uncompressed data segment occurs due to some factors at an intermediate node such as the eNB 300, compressed data segments cannot be decoded during a certain time until the UE 400 can receive the subsequent uncompressed data segment (in the meantime, silence occurs).
The reason is as follows. If a data segment, especially an uncompressed data segment is missing, the header of header-compressed data segments (compressed data segments) cannot be decompressed until the subsequent uncompressed data segment is received by the UE (the ROHC decompressor), in the header compression algorithm of the ROHC.
For example, in the RLC processor 303 of the eNB 300, for real-time data such as audio data, data residing for more than a predetermined time is discarded by an RLC discard function. The RLC processing has three modes: an AM mode, a UM mode, and a TM mode. The UM mode or the TM mode that does not require a response from the counterpart is applied to an audio packet. The RLC discard function operates in the UM mode.
Therefore, under congestion, discard by the function may occur. FIG. 21 illustrates such a case.
As illustrated in FIG. 21, when discard of an uncompressed data segment is generated by the RLC discard function in the RLC processor 303 of the eNB 300, the UE 400 cannot receive the uncompressed data segment (see the dotted arrow). For this reason, the UE 400 (the PDCP processor 403) cannot decompress the header of received compressed data segments until the subsequent uncompressed data segment can be normally received, so that audio data segments (AMR/RTP/UDP/IP packet data segments) cannot be decoded correctly. Compressed data segments that cannot be decoded are discarded by the UE 400.
If the UE 400 cannot receive normally an uncompressed data segment addressed to the UE 400 due to discard or missing of the data segment, for example, on the midway, such as the eNB 300, the UE 400 cannot decompress the compressed header of packet data (compressed data segments) to be subsequently received. This significantly precludes voice reproduction until the subsequent uncompressed data segment is received. The compressed data segments received by the UE 400 before this time are wastefully discarded, resulting in loss of the downstream wireless band (wireless resources).